Configure System:

    DEP=OptIn SEHOP=OptIn ASLR=OptIn

Configure Apps:

    wfica32.exe: everything not checked

Restart system, and run:

    Procexp shows:  EMET.dll loaded, and env EMET_Settings is correct: DEP:0;SEHOP:0;NullPage:0;HeapSpray:0;EAF:0;MandatoryASLR:0

    but it also reports: DEP(permanent), ASLR: Enabled

and the start address of ws2_32.dll turns out to be randomized

I'm running win7 x64, what's wrong with the EMET setting?

Thanks in advance. Regards

Hi ida2009,

From what I can tell, this could be expected behavior. Please allow me to explain:

Your EMET settings will have no effect on this process (wfica32.exe, Citrix ICA Client Engine (Win32)) since all of your EMET mitigations are disabled.

However as you mention the status from within Process Explorer is DEP (Permanent) with ASLR enabled. Process Explorer shows these designations since Process Explorer only queries the OS implementation of ASLR and DEP (see page 30 of the EMET 3.0 User Guide for this info).

DEP Permanent means that the process is opting into the OS (i.e. Windows) implementation of DEP and has been compiled with the /NXCOMPAT linker option. Since it is also reporting ASLR within Process Explorer, it would appear that this process was also compiled with the /DYNAMICBASE linker option.

ASLR and DEP (Permanent) are explained in the following blog posts:

http://blog.eeye.com/general/dep-down-part-1

http://securitywatch.pcmag.com/none/284144-what-s-your-dep-and-aslr-status

How we can tell if the is the case is by using Process Explorer for further investigation. Please enable the following option from within Process Explorer:

Options->Configure Colors->Relocated DLLs

Please tick/check the box to the left of this option as shown in the screenshot below:

Direct Link To Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessExplorerRelocateDLLsOption.png

If a DLL is not opting into ASLR, EMET will relocate that DLL (i.e. randomly place that DLL within memory) if ASLR:1 within EMET. If this is occurring, such re-locations will show as Pink (by default) in Process Explorer version 15.3.

In addition, such DLLs will not show ASLR but will be blank in the ASLR column of the DLL lower pane of Process Explorer. This is shown in the screenshot below (you may need to zoom in on this screenshot to see this). The process FAHControl.exe does not opt-into DEP or ASLR (however the Microsoft DLLs it uses do), the remainder are 3rd party DLLs which are then re-located by EMET using EMET's ASLR implementation that Process Explorer will not show in its ASLR column (instead it is shown by the colored highlighting).

Direct Link To Image:

http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessExplorerRelocatedDLLs.png

Such re-location of DLLS is explained in the following EMET thread:

http://social.technet.microsoft.com/Forums/en-US/emet/thread/2208281f-ef4e-412d-ad7f-cd2f36404eb6

In the above screenshot, the .exe file of FAHControl.exe is not re-located by EMET (it is shown in white, not pink) since .exe files cannot be protected by EMET, only the DLLs within an .exe file can be protected. This is expected behavior and is by design. This is mentioned by Didier Stevens in the following YouTube video (see position 03:40 within that video):

http://www.youtube.com/watch?v=zDZWgsJFEp4

If you do NOT see the colored highlighting within the wfica32.exe process using Process Explorer, you will know that EMET is NOT affecting these DLLs. In addition Process Explorer will show ASLR for those DLLS if they are opting into ASLR (which is not controlled by EMET) due to being compiled with /DYNAMICBASE linker option. This would explain why the DLLs are randomized even though EMET has Mandatory ASLR disabled. This is expected behaviour since if the DLLs are using ASLR, EMET will NOT apply Mandatory ASLR to those DLLs (this prevents the DLLs from being re-located twice).

If the DLLs are being re-located and do NOT show ASLR is Process Explorer this is NOT expected behaviour and is a bug within EMET (since you have Mandatory ASLR of EMET disabled and thus EMET should have no effect).

I hope that I have explained how you can tell if what you are experiencing is intended behavior or not. If you require additional clarification or further assistance, please let me know.

Thank you.

If the DLLs are being re-located and do NOT show ASLR is Process Explorer this is NOT expected behaviour and is a bug within EMET (since you have Mandatory ASLR of EMET disabled and thus EMET should have no effect).

DLL relocation IS expected standard behavior (and necessary) when the DLL's preferred load address (Image Base in Process Explorer) is unavailable/already occupied... AFAIK, EMET just makes sure that happens by reserving a small amount of memory at x address (if it's free) before the DLL gets loaded.

Hi DR_LaRRY_PEpPeR,

Youre correct. That is how Mandatory ASLR works. This is mentioned by Didier Stevens in the video that I linked to above (mentioned at approximately 04:45 within that video).

Thanks.

Hello,

I found this thread, and two associated threads on ASLR most helpful. Please let me summarize their salient points:

• It is a well-known fact that native system ASLR and EMET's Mandatory ASLR are two different things.
• EMET's mandatory ASLR works a little bit different from the OS's ASLR. See the User Guide (Point 7.2)
  
• EMET is only able to force-relocation on DLLs that load after the EMET.DLL. When EMET loads it hooks LdrLoadDll and checks each module for the IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE bit and if it is not present... allocates a page at the DLL image base to force the operating system to load the DLL at another virtual address.
  
• The 'ASLR' column in the Process Explorer process list is only checking the PE image characteristics for the IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE bit. (Understand the role of the /DYNAMICBASE linker option.)
• DLL relocation is expected, standard behavior, and necessary when a DLL's preferred load address is taken. (Explains why relocation occurs even when EMET's Mandatory ASLR is disabled/unchecked.)
• EMET's Mandatory ASLR does not relocate the base address of the executable (Again EMET.dll loads after the exe; it's just not possible for EMET to change the image address of the exe.)
• Enable the following option from within Process Explorer: Options->Configure Colors->Relocated DLLs, to see relocation in action.
  

I cannot take credit for these insights. Kudos to the forum members responsible for these.

Please, let me know if my thoughts are correct:

1. EMET's system wide ASLR setting is not related to the OS ASLR configuration KB 2639308
2. EMET's system wide ASLR option implements the same mitigation as EMET's Mandatory ASLR mitigation under the "Configure App" window. [This is false. See below.]
   
3. By Setting EMET's system wide ASLR option to "OptIn", you have opt'ed to turn on EMET's ASLR for every program. This means theat EMET's ASLR will relocate every application DLL that were not compiled for OS ASLR. [This is false. See below.]
   
4. By Disabling EMET's system wide ASLR setting, you now rely on EMET's Mandatory ASLR check mark to determine whether EMET's ASLR is applied or not.

I would have revised my questions but Dr_Larry_Pepper had already provided additional insight.

First of all, anyone, Process Explorer's DEP status is BROKEN since v15.13 for Windows 7/8. I discovered this when testing my "Permanent DEP" DLL and stuff (voidmain.realplain.com, first draft info from last week, sorry; /spam). On Windows 7, it indicates that DEP is On, even when it's NOT! And on Windows 8, it shows (permanent) even when it's not (I can turn it off, with my SetDEP program, etc.). I've tried to tell Mark Russinovich about it...

canaryNumber5:

1. Right, EMET's system wide setting is using the MoveImages setting that "has no effect in Windows 7" (hah!): en.wikipedia.org/wiki/Address_space_layout_randomization#Microsoft_Windows
2. I wouldn't say that, no. Although the end result may appear similar.
3. No, EMET's "MandatoryASLR" should still be controlled by each program's check mark. Also, isn't OptIn System ASLR the default? e.g. doesn't have to be set in EMET's interface...
4. Yeah, but that would only apply to stuff dynamically loaded after EMET.dll, as you said previously, and I think isn't as good? I don't really think System ASLR should be disabled for any reason...?

1. I am beginning to understand the ASLR policy: System Wide ASLR abides by the DYNAMICBASE linker flag. Disabling system wide ASLR ignore the flag. Continuing with the numbering:
   
2. Then EMET's Mandatory ASLR mitigation randomizes the base address of the non-ASLR DLLs.
3. By setting EMET's system wide ASLR option to "OptIn", the program's base address will be randomized if the program was compiled with DYNAMICBASE.
4. By disabling EMET's system wide ASLR setting, the DYNAMICBASE option is ignored; the (preferred and fixed) image address is used.

The OS ASLR configuration can set a per application registry key to forcibly relocated images that are not built with the DYNAMICBASE linker flag. [KB 2639308]

I will have to test and determine if this IFEO key is a substitute for DYNAMICBASE. My tests continue.